做系統維運一段時間後，我慢慢發現一件事情：

很多工作其實不難，真正讓人花時間的，反而是那些每天、每週、每個月都要重複做的事情。

例如：

查詢 Active Directory 帳號狀態
確認使用者是否被停用
找出長時間沒有登入的帳號
查詢電腦物件
確認 Windows Server 的磁碟空間
檢查 Service 是否正常
查看 Event Log
整理 CSV 報表
在不同 Server 上重複執行相同指令

這些工作單獨看可能都只需要幾分鐘。

但如果今天不是一台 Server，而是 10 台、20 台；不是一個帳號，而是幾百、幾千個 AD 物件，原本幾分鐘的工作就會慢慢累積成大量的人工操作。

所以這次的 30 天，我想做的事情很單純：

把系統工程師每天會遇到的重複工作，一步一步改成自動化。

為什麼我會想寫這個系列？

系統工程師的工作範圍其實很廣。

有時候是在處理 Windows Server，有時候是在查 AD，有時候是在排查 DNS、Service 或使用者端的問題。

真正遇到問題時，也很少只是輸入一個指令就結束。

例如今天收到一個需求：

「可以幫忙確認這批 AD 帳號哪些已經很久沒有登入了嗎？」

如果帳號只有 5 個，也許直接打開 Active Directory Users and Computers，一個一個看就好。

但如果今天是：

100 個帳號
500 個帳號
1000 個帳號

這時候繼續用滑鼠一個一個點，事情就開始不太對了。

而且人工操作還有另一個問題：

容易漏掉。

可能第 37 個帳號看錯、某一欄忘記複製，或是在整理 Excel 時貼錯資料。

這些事情不是技術很困難，而是人工重複操作本身就容易出錯。

Automation 不一定要從很大的系統開始

以前想到「自動化」，很容易先想到：

CI/CD
Ansible
Terraform
Kubernetes
Cloud

這些當然都是很重要的技術。

但實際在企業 IT 環境裡，我覺得還有另外一種很實際的自動化：

先把自己每天重複做的事情自動化。

例如原本：

打開 AD
↓
搜尋帳號
↓
開啟 Properties
↓
查看狀態
↓
複製資料
↓
貼到 Excel

如果改成 PowerShell：

Get-ADUser -Filter *

雖然只是一條指令，但思考方式已經開始不一樣了。

我們不再問：

我要怎麼比較快地一個一個查？

而是開始問：

我能不能一次把我要的資料全部抓出來？

這也是我認為開始接觸自動化最重要的一個轉變。

從 GUI 思維改成資料思維

Windows 系統管理很多時候都是從 GUI 開始。

例如管理 AD 時，我們可能會開：

Active Directory Users and Computers

管理 Service 時會開：

services.msc

查看事件時會開：

Event Viewer

這些工具非常好用，我自己也還是會使用。

所以這個系列不是要說：

GUI 不好，以後所有事情都要 PowerShell。

而是當工作開始大量、重複，甚至需要定期執行時，就可以思考：

這件事情是不是比較適合交給程式處理？

例如我要查詢 Windows Service。

GUI 的方式可能是：

Win + R
↓
services.msc
↓
尋找服務
↓
確認 Running / Stopped

PowerShell 則可以直接：

Get-Service

如果只想看正在執行的 Service：

Get-Service |
Where-Object Status -eq "Running"

甚至可以把結果：

查詢
↓
篩選
↓
排序
↓
輸出 CSV
↓
寄送報表

全部串在一起。

這時候 PowerShell 就不只是「比較快的 CMD」。

它開始變成一個維運工具。

自動化真正想解決的是什麼？

我認為自動化的目的不是：

「證明我會寫 PowerShell。」

而是解決幾個實際問題。

1. 減少重複操作

假設每天都需要檢查：

CPU
Memory
Disk
Service
Event Log

每天人工登入 Server 檢查一次，也可以完成。

但如果每天都做一樣的事情，其實就很適合交給程式。

2. 降低人為錯誤

人工整理：

Hostname
IP
Disk Usage
Service Status

很容易 Copy / Paste 錯誤。

如果讓程式直接取得資料並輸出 CSV，格式就會固定很多。

3. 增加處理規模

人工查 3 台 Server 沒什麼問題。

但是：

3 台 Server
↓
30 台 Server
↓
300 台 Server

處理方式一定需要改變。

自動化最大的優勢之一，就是可以把：

「我會處理一台機器」

慢慢變成：

「我可以用同一套方法處理很多台機器。」

4. 把時間留給真正需要判斷的事情

有些事情程式很適合做：

收集資料
比對資料
篩選資料
產生報表
定期執行

但有些事情仍然需要工程師判斷：

為什麼服務會停止？
這個帳號到底能不能停用？
這個 Event 是否真的代表異常？
這台 Server 為什麼突然變慢？

所以我比較希望做到的是：

程式負責重複工作

工程師負責判斷問題

而不是讓工程師把大量時間花在 Copy、Paste、Click。

這 30 天會做什麼？

這次我會以三個主要環境為核心：

PowerShell
│
├── Active Directory
│
└── Windows Server

前半段先從 PowerShell 基礎開始。

但不會單純介紹：

變數是什麼
If 是什麼
For 是什麼

我會盡量把它放進實際維運情境。

例如：

Get-Service
Get-Process
Get-EventLog
Get-WinEvent
Get-ADUser
Get-ADComputer

慢慢做到：

AD 帳號查詢
↓
Inactive Account 盤點
↓
電腦物件盤點
↓
CSV 報表
↓
Server 健康檢查
↓
多台 Server 巡檢
↓
排程執行
↓
錯誤處理
↓
維運工具箱
我希望最後不是留下 30 支零散 Script

這次我不希望最後變成：

script01.ps1
script02.ps1
script03.ps1
script04.ps1
...

然後過了半年，連自己都不知道每一支是做什麼的。

我希望最後可以慢慢整理成類似：

SysAdmin-Toolkit
│
├─ AD
│ ├─ Get-InactiveUsers.ps1
│ ├─ Get-ADComputers.ps1
│ └─ Export-ADReport.ps1
│
├─ Server
│ ├─ Get-DiskUsage.ps1
│ ├─ Get-ServiceStatus.ps1
│ └─ Get-ServerHealth.ps1
│
├─ Reports
│
└─ Logs

也就是一套自己真正可以重複使用的：

System Engineer Automation Toolkit

這才是我這 30 天真正想完成的東西。

Day 1 小結

第一天先不急著寫複雜的 Script。

今天比較想先確定一件事情：

自動化不一定要從很複雜的技術開始。

有時候它只是從：

「這件事情我是不是已經做第三次了？」

開始。

如果同樣的工作一直重複發生，就值得想一下能不能把流程標準化，再進一步交給 PowerShell 執行。

這也是接下來 30 天我會一直使用的思考方式：

先人工做一次
↓
了解操作流程
↓
找出重複步驟
↓
PowerShell 化
↓
批次處理
↓
加入錯誤處理
↓
排程與自動執行

我們不會一開始就做一套很大的系統。

而是從每天真的會碰到的小事情開始。